Delivery of significant volumes of data to multiple users, or end hosts, can impose a significant burden on a network. Data can be broadcast over the network and picked up by receivers interested in obtaining the data. However, there may be whole sections of a network in which there is no receiver who wishes to obtain the data so broadcasting data to these network portions wastes network bandwidth. An alternative approach is to send data directly to only those users who have requested the data using unicast methods. However, this can result in large amounts of replicated content being transmitted over the network, which again can cause congestion in the network and affect reliability and Quality of Service (QoS) for other data being transmitted in the network.
Multicasting techniques can be used to distribute content more efficiently in a network by ensuring that content is not replicated in the network until paths to its intended destinations split in the network topology.
The delivery of on-demand content poses a particular problem, however, since multiple users may request the same content at different times and each user may wish to pause or rewind the content stream during playback of the media. Delivery of such on-demand content by unicast enables a user to start viewing a stream at any time and to pause and rewind the stream. However, unicasting of all content is undesirable in most networks since it results in significant replication of the content transmitted over the network and consumes large amounts of network bandwidth.
There are difficulties in using multicast delivery techniques to deliver on-demand content to several end hosts; for example, the multicast stream cannot be paused or rewound for a single user wishing to join the stream at a later stage, as might be the case in uptake of on-demand content. This might result in the new host having to set up and receive a unicast stream for the content, no matter how little ahead in time the multicast stream might be from the start of the piece of content.
According to a further aspect, there is provided a method of distributing content from a source to at least one destination in a content delivery network, the method comprising:                processing the content to generate a plurality of multicast streams for transmitting the content, wherein at least some of the content is delivered by more than one of the multicast streams;        determining a relative time-shift, M, between transmission of the same portion of the content in different multicast streams;        processing the plurality of multicast streams to implement the relative time-shift, M, between transmission of the same portion of the content in the multicast streams;        transmitting the content to the destination using a subset of the multicast streams, wherein the subset comprises at least two selected ones of the plurality of multicast streams.        
Hence the method enables the generation of multiple time-shifted multicast streams with a selected time-shift between them, which can provide an efficient way to deliver content in a network. A single destination joins multiple multicast streams to enable the content to be delivered more quickly.
Optionally, the selected ones of the plurality of multicast streams are selected by a content delivery management device implemented in the network or at the source. Hence components in the network, rather than the destination, select the streams used for delivery of the content. This can enable the network to control how the content is delivered to the destination so that network components can manage the growth of multicast trees in the network and can take into account factors such as network congestion and topology information in determining which streams to use to deliver the content.
Optionally, each multicast stream is arranged to deliver substantially the whole content. Therefore, a single multicast stream would be sufficient to receive the content, however, the use of multiple streams to deliver the same piece of content provides advantages such as those described herein. The skilled person will appreciate however that, for selected streams, it may not be necessary to deliver all of the content. For example, a multicast stream may be started half an hour into the content if it is determined that such a stream is needed.
The time delay, M, will depend on one or more factors determined by the network, as described in more detail below. However, M is optionally of the order of a few minutes depending on the requirements of the system and the length of the piece of content being delivered. M may be around 10 minutes or 30 minutes. Optionally M is less than an hour.
In one embodiment, the relative time delay, M, is the same between each of the multicast streams. Hence, multicast streams may be staggered in a regular, periodic manner.
In some embodiments, the relative time delay between a first and a second multicast stream, M1, is different to the relative time delay between the second and a third multicast stream, M2. For example, when requests for a piece of content are being received at a high rate, the delay between different multicast streams may be short, for example around 5 minutes, so that several different multicast streams are available to deliver the content. However, as the requests slow down, the delay between multicast streams can be extended, for example to around half an hour, to provide the multiple multicast delivery but to fewer destinations.
In some embodiments the time delay, M, M1 or M2 is determined based on the buffer capacity of the at least one destination and/or a determination of the number of streams that can be simultaneously received by the destination. For example, if a destination can join three multicast streams for a single piece of content, and has a buffer that can store up to 1 hour of content, the three multicast streams that the destination is instructed to join can start at 0 minutes, 30 minutes and 1 hour into the content.
The at least one destination may comprise a plurality of destinations and the time delay can then be determined based on the buffer capacity of the destination having the smallest buffer capacity, the mean buffer capacity of the destinations or the modal buffer capacity of the destinations.
In some embodiments, the time delay M, M1 or M2 is determined based on a model of predicted requests for the content.
Optionally, the model of predicted requests determines the expected number of requests or the expected rate of requests for the content over a subsequent time period.
Further optionally, the model of predicted requests determines the expected geographical or topological distribution of requests over a subsequent time period.
In some embodiments, the time delay M, M1 or M2 is determined based on the rate of requests for the content in a preceding time period. As noted above, when requests are being received at a high rate, more multicast content streams may be created with a smaller time delay therebetween.
In some embodiments, the time delay M, M1 or M2 is determined based on a measure of the network capacity or availability between the source and the at least one destination.
Optionally, the time delay, M is determined based on a combination of the factors set out above.
In a particular embodiment, the method further comprises receiving a request from a destination for the content; identifying a the subset of multicast streams for transmitting the content to the destination; and generating a unicast stream for transmitting to the destination a portion of the content not available in the multicast streams. In particular, a unicast stream transmitted to a particular destination may supplement the multicast streams by transmitting a beginning portion of the content if all of the multicast streams are already some way through the content.
A number of aspects of embodiments of the system have been described above. It will be clear to one skilled in the art that each of these aspects may be implemented independently. However, the aspects are optionally implemented in conjunction with each other to provide multiple advantages as part of a larger system. Features of one aspect may be applied directly to other aspects of the system. Further, method features may be applied directly to aspects of the apparatus.
In particular, in all of the aspects described above, the destination may be a host or a host designated router, H-DR, in a multicast network. The host may be the end user terminal associated with an end user or consumer of the content or may be an intermediate device that serves the content to the user's device. For example, the destination may be a hub within a home network that receives the content for streaming to a user's terminal, such as an internet-connected television, a computer, a tablet or a telephone.
Similarly, in all of the aspects described above, the source may be the device that serves the content in the network or may be an intelligent routing component in the network that handles routing of content to destinations. The content may pass through the intelligent routing component, or the component may control other components in the network, such as the source, to implement the methods described herein.
Further, in all of the aspects set out above, the content is optionally video content and/or audio content, in particular on-demand content delivered in response to a request from a user. However, the skilled person will appreciate that the systems and methods described herein could equally be applied to networks for the distribution of data, such as text or image data, or software.